{"id":38329,"date":"2011-05-04T08:05:40","date_gmt":"2011-05-04T08:05:40","guid":{"rendered":"https:\/\/www.vmengine.net\/2011\/05\/04\/falla-del-centro-de-datos-el-tiempo-de-inactividad-no-es-una-opcion\/"},"modified":"2025-05-23T17:09:36","modified_gmt":"2025-05-23T17:09:36","slug":"falla-del-centro-de-datos-el-tiempo-de-inactividad-no-es-una-opcion","status":"publish","type":"post","link":"http:\/\/temp_new.vmenginelab.com\/es\/2011\/05\/04\/falla-del-centro-de-datos-el-tiempo-de-inactividad-no-es-una-opcion\/","title":{"rendered":"Falla del centro de datos: el tiempo de inactividad no es una opci\u00f3n"},"content":{"rendered":"

\"\"<\/a> Hablamos de datos evaporados, turbulencias, huracanes, tormentas, cada uno usa su propia met\u00e1fora asociada a las nubes, precisamente porque hablamos de computaci\u00f3n en la nube, recuperaci\u00f3n de desastres, tiempo de inactividad en los centros de datos. Estamos hablando de Amazon Web Service<\/strong>, Aruba<\/strong>, Google Mail<\/strong>, sistemas de almacenamiento en cl\u00faster, estamos hablando de datos centralizados, servicios centralizados en centros de datos que se crean para hacer este trabajo, errores humanos, errores de planificaci\u00f3n y tambi\u00e9n la ligereza de los clientes al confiar completamente sin quiz\u00e1s haber le\u00eddo los contratos SLA, sin haber implementado correctamente su sistema con los servicios prestados por el proveedor, Por \u00faltimo, sin haber valorado los da\u00f1os econ\u00f3micos y de imagen derivados del tiempo de inactividad, la famosa continuidad del negocio<\/strong>.<\/p>\n

Interrupci\u00f3n de AWS<\/h1>\n

Empecemos por Amazon, como ya se indic\u00f3 en este<\/span> otro post<\/a> el pasado 21 de abril se produjeron problemas en un centro de datos en la zona este-ee.uu. (Virginia), en los <\/span>servicios fundamentales EC2 <\/strong><\/p>\n

<\/span>y <\/span>RDS<\/strong><\/p>\n

<\/span>. Estos han fundamentado algunos servicios sociales famosos de Internet, como <\/span>Foursquare<\/strong>, <\/span>Reddit <\/strong>y <\/span>Quora<\/strong>.<\/span><\/p>\n

Pero NetFlix<\/strong>, Twilio<\/strong> y otros, aunque utilizaron recursos en la misma zona de disponibilidad, no sufrieron el mismo destino, el propio Reddit <\/strong>volvi\u00f3 a estar en l\u00ednea casi de inmediato gracias a un s\u00f3lido contrato de soporte con Amazon que le garantizaba ingenieros dedicados. Amazon nos da un resumen <\/a>al final de la historia donde ilustra lo que sucedi\u00f3 y c\u00f3mo manejaron el evento, lo que aprendieron y c\u00f3mo se mover\u00e1n en el futuro inmediato para evitar que vuelva a suceder, se disculpan con todos los clientes y hablan sobre el reembolso de cr\u00e9ditos para los clientes. Obviamente, el reembolso no se mide en funci\u00f3n de la magnitud del da\u00f1o sufrido, sino que esto depende del tipo de contrato que celebre con el proveedor.<\/p>\n

Problemas de sincronizaci\u00f3n de almacenamiento de EBS<\/h3>\n

Para el servicio EC2 <\/strong>, el desencadenador era un subconjunto de discos EBS <\/strong>en una zona de disponibilidad. Parece que se han congelado, sin poder leer y escribir, obviamente las instancias que depend\u00edan de estos discos tambi\u00e9n estaban bloqueadas. Deshabilitaron las API de control de este cl\u00faster de EBS en esa \u00e1rea afectada. En este punto, Amazon explica brevemente c\u00f3mo funciona el servicio de disco EBS y su cl\u00faster. Como muchos expertos ya habr\u00e1n adivinado, EBS es un almacenamiento distribuido, que consta de una serie de cl\u00fasteres que contienen datos en replicaci\u00f3n consistente y a nivel de bloque entre s\u00ed, y una serie de otros sistemas \u00fatiles para coordinar las solicitudes de los usuarios a los nodos. Las r\u00e9plicas de datos entre los nodos del cl\u00faster est\u00e1n garantizadas por una estrategia de conmutaci\u00f3n por error r\u00e1pida punto a punto para desencadenar nuevas r\u00e9plicas si una deja de estar sincronizada o ya no est\u00e1 disponible. Los nodos est\u00e1n conectados entre s\u00ed por dos redes, la primera de banda ancha y la secundaria de menor capacidad utilizada como red de respaldo y expansi\u00f3n para la replicaci\u00f3n de datos. La segunda red no se cre\u00f3 para gestionar todo el tr\u00e1fico de la primaria, sino para proporcionar una conectividad muy fiable entre los nodos.<\/p>\n

El problema surgi\u00f3 debido a un error humano<\/span> durante una actividad de escalado normal de la red primaria de un cl\u00faster de EBS, se supon\u00eda que el cambio servir\u00eda para aumentar su capacidad, pero el tr\u00e1fico que se deb\u00eda mover para transferir la actualizaci\u00f3n se transfiri\u00f3 por error a la red secundaria que no se mantuvo y las r\u00e9plicas saltaron. Obviamente, el problema del almacenamiento de EBS tambi\u00e9n ha afectado al servicio de base de datos relacional RDS <\/strong>, que depende totalmente de \u00e9l<\/p>\n

Seg\u00fan un an\u00e1lisis de RightScale <\/strong>habr\u00eda habido m\u00e1s de 500k <\/strong>vol\u00famenes de EBS afectados, tambi\u00e9n afirma que un evento de esta magnitud supera los par\u00e1metros de dise\u00f1o, no se puede probar y que no hay un sistema de escala comparable en funcionamiento en ning\u00fan otro lugar.<\/p>\n

Amazon afirma que realizar\u00e1 una serie de cambios para mejorar y evitar la repetici\u00f3n de este tipo de eventos.<\/p>\n

Un comentario interesante de Lew Moorman de Rightscale<\/strong> en una entrevista con el
\n New York Times<\/a>
\n<\/strong> : \u00abLa interrupci\u00f3n de Amazon es el equivalente cibern\u00e9tico de un accidente a\u00e9reo. Este es un episodio importante con da\u00f1os generalizados. Pero los viajes a\u00e9reos siguen siendo m\u00e1s seguros que los viajes en coche, de forma an\u00e1loga a que la computaci\u00f3n en la nube sea m\u00e1s segura que los centros de datos gestionados por empresas individuales. Todos los d\u00edas, en empresas de todo el mundo, hay interrupciones de tecnolog\u00eda, cada episodio es muy peque\u00f1o, pero puede desperdiciar m\u00e1s tiempo, dinero y negocios\u00bb.<\/p>\n

Lecciones de AWS y los enfoques correctos para usarlo<\/h3>\n

\u00bfQu\u00e9 puede hacer el cliente para utilizar correctamente los servicios mencionados para superar los problemas t\u00e9cnicos del proveedor? En primer lugar, el servicio EC2 utilizado de forma sencilla e individual no garantiza una alta disponibilidad, sino que tiene un SLA del 99,95%, lo mismo se aplica a RDS que depende de EC2 y EBS. Pero la propia Amazon comunica que un correcto uso de los servicios conduce a soluciones altamente fiables. Por ejemplo, el uso de varias zonas de implementaci\u00f3n (NetFlix <\/strong>usa tres), el uso de instant\u00e1neas de EBS crea la capacidad de replicar el volumen en otras zonas de disponibilidad (la instant\u00e1nea <\/strong>se encuentra f\u00edsicamente en el sistema S3), realizar copias de seguridad de datos en S3, copias de seguridad e instant\u00e1neas <\/strong> de RDS, o incluso habilitar la replicaci\u00f3n en varias zonas de<\/strong> disponibilidad (entre diferentes zonas de disponibilidad). Estos son los enfoques que han impedido que ciertos clientes est\u00e9n desconectados a pesar de los problemas del proveedor.<\/p>\n

Aruba<\/strong><\/h1>\n

Sobre la base de las declaraciones de Aruba en la siguiente comunicaci\u00f3n: http:\/\/ticket.aruba.it\/News\/212\/webfarm-arezzo-aggiornamenti-3.aspx<\/a><\/p>\n

Esta ma\u00f1ana a las h. 04:30, un cortocircuito que se produjo dentro de los armarios de bater\u00edas que serv\u00edan a los sistemas UPS de la granja de servidores Arezzo de Aruba provoc\u00f3 un incendio: el sistema de detecci\u00f3n de incendios entr\u00f3 en funcionamiento inmediatamente, que en secuencia apaga el aire acondicionado y activa el sistema de extinci\u00f3n. Como el humo liberado por la combusti\u00f3n de las bater\u00edas de pl\u00e1stico invadi\u00f3 por completo las instalaciones de la estructura, el sistema interpret\u00f3 la persistencia del humo como una continuaci\u00f3n del incendio y cort\u00f3 autom\u00e1ticamente la electricidad.<\/em><\/p>\n

El sistema UPS deber\u00eda ser un interruptor de la fuente de alimentaci\u00f3n principal, mientras que un error de dise\u00f1o (error humano<\/span>) del sistema de ventilaci\u00f3n de la sala UPS, provoc\u00f3 el apagado de todos los sistemas, lo que para el mercado italiano signific\u00f3 la desconexi\u00f3n de millones de sitios de clientes. Como dice la propia Aruba en la nota de prensa, este error se solucionar\u00e1:<\/p>\n

Adem\u00e1s, aunque es costumbre instalar bater\u00edas dentro del centro de datos, para evitar que se repita lo sucedido, a partir de hoy las bater\u00edas del centro de datos de Arezzo y todos los dem\u00e1s centros de datos del Grupo Aruba se instalar\u00e1n en salas especiales, externas y separadas de la estructura principal.<\/em><\/p>\n

Google Gmail<\/h1>\n

En el caso de la interrupci\u00f3n de algunos clientes de correo de Gmail el pasado mes de febrero, como se comunic\u00f3 en http:\/\/static.googleusercontent.com\/external_content\/untrusted_dlcp\/www.google.com\/it\/\/appsstatus\/ir\/nfed4uv2f8xby99.pdf<\/a>, la interrupci\u00f3n fue causada por un error introducido inadvertidamente en una actualizaci\u00f3n de software (error humano<\/span>), y para evitar problemas de integridad de los datos que inhabilitaran el acceso a Google Apps para el n\u00famero de clientes afectados, el equipo de ingenier\u00eda tuvo que restaurar los buzones de correo de las cintas de copia de seguridad, confirmando que las copias de seguridad en cinta siguen en uso y siguen siendo fiables.<\/p>\n

Conclusiones<\/h1>\n

A pesar de estos incidentes, como dice Lew Moorman en la entrevista del NYT, los grandes centros de datos gestionados por estas grandes entidades son siempre m\u00e1s seguros que las soluciones que podr\u00edan adoptar las peque\u00f1as y medianas empresas.<\/p>\n

En su lugar, la discusi\u00f3n deber\u00eda trasladarse a un tema muy complejo que parte de la siguiente observaci\u00f3n:<\/p>\n

porque Facebook, Google y Amazon construyen servidores (Facebook y Google espec\u00edficamente), centros de datos (ver Facebook OpenCompute <\/a>Project), modifican o crean proyectos de software de c\u00f3digo abierto para sus propias necesidades (ver Bigtable de Google), por ejemplo los sistemas de almacenamiento S3 EBS (parecen usar DRDB<\/a>), SDB, donde el coraz\u00f3n palpitante son las bater\u00edas de servidores cl\u00e1sicos pero potentes, Sistemas de red dedicados que replican datos entre los numerosos nodos, es decir, soluciones de software propietario o modificaciones de proyectos de c\u00f3digo abierto nacidos en alguna universidad del mundo y tal vez a\u00fan en desarrollo en alguna parte mundial.<\/span><\/em><\/p>\n

la pregunta es provocadora para los proveedores de maxi sistemas (IBM, HP, Dell, etc), pero la respuesta podr\u00eda estar en las siguientes publicaciones antiguas ( Tecnolog\u00eda Isilon<\/a><\/a>, EMC compra Isilon<\/a><\/a>, HP compra LefHand<\/a><\/a>, y otras adquisiciones recientes), es decir, los grandes proveedores hace solo unos a\u00f1os comenzaron a entender la necesidad de especializarse en sistemas de almacenamiento distribuido en cl\u00faster, porque solo estos sistemas tienen la capacidad de responder a grandes cantidades de datos y grandes necesidades de ancho de banda y acceso simult\u00e1neo, adem\u00e1s de las enormes necesidades de Amazon, Google, Facebook inclina la balanza econ\u00f3mica hacia soluciones abiertas o propietarias en comparaci\u00f3n con los costos de licencia y soporte que tendr\u00edan a trav\u00e9s de los proveedores del pasado.<\/p>\n

En definitiva, la mayor\u00eda de las soluciones de software o hardware de los servicios que utilizamos y utilizaremos cada vez m\u00e1s, pertenezcan o no al paradigma de la computaci\u00f3n en la nube, son sistemas que, por su tama\u00f1o y alcance, nunca ser\u00e1n probados de forma efectiva para evitar el desastre.<\/p>\n","protected":false},"excerpt":{"rendered":"

Hablamos de datos evaporados, turbulencias, huracanes, tormentas, cada uno usa su propia met\u00e1fora asociada a las nubes, precisamente porque hablamos de computaci\u00f3n en la nube, recuperaci\u00f3n de desastres, tiempo de inactividad en los centros de datos. Estamos hablando de Amazon Web Service, Aruba, Google Mail, sistemas de almacenamiento en cl\u00faster, estamos hablando de datos centralizados, […]<\/p>\n","protected":false},"author":2,"featured_media":38330,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[96],"tags":[2037,1397,146,2038,2039,2040,2041,1290,147,2022,149,1086,2042,2043,2044,2024,2045,2025,244,2046],"class_list":["post-38329","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-sin-categorizar","tag-apagon-de-aruba","tag-centro-de-datos","tag-computacion-en-nube","tag-continuidad-del-negocio","tag-desastre-de-aruba","tag-desastre-de-aws","tag-disaster-recovery-es","tag-ebs-es","tag-ec2-es","tag-foursquare-es","tag-historias","tag-instantanea","tag-interrupcion-de-aws","tag-interrupcion-de-gmail","tag-multi-az-es","tag-quora-es","tag-rds-es","tag-reddit-es","tag-tecnico","tag-tiempo-de-inactividad"],"aioseo_notices":[],"jetpack_featured_media_url":"http:\/\/temp_new.vmenginelab.com\/wp-content\/uploads\/2011\/04\/dilbert-downtime1-2.jpg","amp_enabled":true,"_links":{"self":[{"href":"http:\/\/temp_new.vmenginelab.com\/es\/wp-json\/wp\/v2\/posts\/38329","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/temp_new.vmenginelab.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/temp_new.vmenginelab.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/temp_new.vmenginelab.com\/es\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"http:\/\/temp_new.vmenginelab.com\/es\/wp-json\/wp\/v2\/comments?post=38329"}],"version-history":[{"count":1,"href":"http:\/\/temp_new.vmenginelab.com\/es\/wp-json\/wp\/v2\/posts\/38329\/revisions"}],"predecessor-version":[{"id":41032,"href":"http:\/\/temp_new.vmenginelab.com\/es\/wp-json\/wp\/v2\/posts\/38329\/revisions\/41032"}],"wp:featuredmedia":[{"embeddable":true,"href":"http:\/\/temp_new.vmenginelab.com\/es\/wp-json\/wp\/v2\/media\/38330"}],"wp:attachment":[{"href":"http:\/\/temp_new.vmenginelab.com\/es\/wp-json\/wp\/v2\/media?parent=38329"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/temp_new.vmenginelab.com\/es\/wp-json\/wp\/v2\/categories?post=38329"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/temp_new.vmenginelab.com\/es\/wp-json\/wp\/v2\/tags?post=38329"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}